Merging this PR will not alter performance

✅ 9 untouched benchmarks

_{Comparing dpinol:align-diffs (f0c228c) with main (2349734)}

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (2349734) to head (f0c228c).

@@            Coverage Diff            @@
##              main       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           34        34           
  Lines         4713      4755   +42     
  Branches      1020      1030   +10     
=========================================
+ Hits          4713      4755   +42     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Sorry, can't merge it without running this code myself. I will review it asap after the vacation.

Sorry, can't merge it without running this code myself. I will review it asap after the vacation.

no hurries!

Good change, I want it in. Suite is green on the branch and the target case works as described, faster too, since fewer entries get built:

shifted list, 1000 elements     main 2.44 ms     this branch 0.20 ms

One thing I want to clarify before merge.

Two entries can land on the same path

>>> from assertpy2._engine._diff import _build_equality_diff
>>> [entry.path for entry in _build_equality_diff([1, 2, 3], [3, 2, 1]).entries]
['[0]', '[1]', '[1]', '[2]']      # main gives ['[0]', '[2]']

[1] twice: once as "expected 2 missing", once as "actual 2 extra". Actual-only entries are numbered in the actual index space, expected-only ones in the expected space, and after a shift those have drifted apart. A reversal also ends up with more entries than before, four against two.

Either number both from one index space, or give inserts and deletes their own path form, as the set diff does with extra/missing. Your call which.

One question

Namedtuples are caught by an earlier branch, plain tuples reach the sequence walker:

>>> [(e.path, e.actual, e.expected) for e in _build_equality_diff((1, 2), (2, 3)).entries]
[('[0]', 1, None), ('[1]', None, 3)]     # main: [('[0]', 1, 2), ('[1]', 2, 3)]

Alignment is right for a sequence used as a collection and wrong for one used as a record, and for a coordinate pair the positional reading is the useful one. Did you consider keeping tuples positional, or is there a case for aligning them that I am missing?